"Managing" Huge Communities
Session Info *Session Name: "Managing" Huge Communities *Session Room & Timeslot: Room 1 @ 11am *Organizer: Tori from Oracle *Note taker: Meghan Gill, @meghanpgill, meghan@10gen.com Notes Tori kicks off with what works in the Java community: *We have user groups because you can't scale one person, and need ways to leverage community leaders to scale out. Recognize community members and encourage them to get groups going. Help make them successful. *Example: Big launch for Java 7. Had a call with Java Champions and asked them for their feedback/ideas, made them ambassadors. Sent boxes with t-shirts, slides, etc. - have a party to celebrate. How do you measure the size of the community? How do you define what the community is? *Java uses external sources and analysts. Can also measure the size of user groups: Roughly 300 JUGs with anywhere from 6 to 40,000 members. *Is everyone who can program in Java a member of the community? or is it self-identified? *Drupal world - lots of people who use Drupal don't even have a drupal.org account, and lots of people with accounts don't contribute. *Active community, user community, customer? Or a self-selected. *Break down by different types. *Ohloh - user community, contributor community. Define along both dimensions. Engagement (e.g. claiming account and contributions). Volunteers or in-house staff? *Java: community manager for online managing volunteers + developer evangelists *Identify community volunteers and delegate to them *Is it common to have one staff member managing volunteers, or multiple volunteers? Especially when managing across regions and cultures. *What about time zones? Try to have people/volunteers/staff in different time zones. *Drupal doesn't have any defined community managers. Self-moderated forums. How do we engage members and get people from inactive --> active? *People want to be engaged, we just need to remove the barriers *Constitution with rules, roles, responsibilities, abilities. Belonging & defining from the beginning. *Defining what the paths are and calls to action. *Clarity and transparency is crucial *Example: Adopt a JSR (java spec) - core group always working on it, with many people on the edges. How do you bridge the gaps? Set a clear path to get involved. Have the JUG watch the process, then get involved. *Some people become super contributors easily while others feel outcast - but we don't know why. Are there demographic factors? Psychological? *One good or one bad experience can become a gate or block. *Focus on the newcomer experience - first week of contributing is crucial, make sure that their intial comments are responded to. *Make it easy to find unanswered questions - either by making them more prominent, or an email digest pointing people to the newcomer or unanswered questions. Leaderboard for volunteers to create a litte competition. *How do you understand logevity? *Segmenting user community by levels of engagement - e.g. by language, groups, etc.--> this can be problematic (e.g. all engineers are English speaking, then the non-English speakers feel that they don't get good technical answers) *Officially designate people for certain regions and languages. Recognized these leaders. *Formal systems for different segments. Example: VMware develops and hires local advocates from the community, so that they're already involved in the community, speak the language, etc. Structure of varous leader / champion programs *Oracle ACE program - will pay for people in certain regions to travel and speak about Oracle products *Teiring communities: One contributor to manage other contributors *Java Champions: Technology and community champions. When you have a critical mass of active groups, you can identify a leader across that region. Directory of champions, community controls who is in there. Could teir this within a region or country. *Functional champions - for particular products or areas. *FIFA World Cup model: global world cup with leagues under it can qualify for. Competition drives cooperation. *Federation structure - different people representing smaller groups Emergent vs. anointed leaders *e.g. Microsoft MVP is a top down model where MSFT designates the MVPs, vs. Google's bottom up model where the community ids the leader (not Google). Give formal structure to an informal system. *Anyone can start a GTUG, but they need a few things to get blessed by Google by being listed in a directory (gives credibility). However, 300 groups and 800 organizers is unmanageable. Need to develop local, regional leaders. *Is that a popularity contest? Or is it a meritocracy? *Define different roles: local technology experts, GTUG organizers, etc. *Who decides what contributions count? Recognizing many different contribution types: Issue trackers, IRC, mailing organizers, event organizers, and more. *Event organizers may not be the same people contributing code, and are often invsibile to tracking tools *Community vs. product/project *Corporate entity behind it vs. community driven (e.g. Drupal) - community grew before we were managing it, now it's hard to manage. Easier when you can set the tone from the beginning. *Siloed into projects, modules - creators own their module, and a mini-community develops. Spreads responsibility through community. That comes from software architecture as well, because Drupal is a pluggable system. Recognition *Recognition is a big motivator? Or are there other reasons? *People contribute becuase they want to create value. *Ubuntu accomplishments - badging system. *Introduction of hierarchy *Recognition can be powerful --> influence. Provide the microphone for those community members. Uncover the really cool stuff and promote it. Ensure that you stay in the trends? *Get out there and talk to people! *Don't always go to the people you already know - bring someone else into the fold Ideal ratios / sub group breakdowns *How much can you effectively manage, and what are the ideal chunk down sizes? *Organic - in some places it's 5, in others it's very large. *Break down when it gets too hard for someone to get things done. What do you do when you have brilliant contributors that are bullies? *Guidelines or code of conduct (see Ubuntu as an example) *But how do you enforce it? *To do: introduce how to for enforcement *"Don't be an asshole" isn't sufficient - how do you enforce that? *Easier to set a tone upfront *Make the decision of whether you want to get rid of the assholes - or grow them into more compatible people? *Need to draw the line *Community manager with reputation/credibility can stop the behavior *Measure ROI on contributors - what if they are the most active contributors, but they're asshole? What about measuring the damage? Are they preventing new contribution? *Is their value in attrition? Smaller but more powerful? Does the need to have things go "up and to the right" encourage the wrong behavior? *Example: GTUG measures engagement vs pure number of members or groups